This application is being filed with an appendix entitled, "Pseudo MDI Architecture and Programmer's Guide, Version 1".
1. Field of the Invention
The present invention concerns a method of and system for generating a user-display interface in a windows operating system. More particularly, the invention concerns a method of and system for generating a user-display interface which displays and closes child windows at positions on a display screen that are independent of the positions of the parent window.
2. Description of the Related Art
Microsoft Windows (hereafter "Windows") is software package commercially available from Microsoft Corporation, which acts as an interface between DOS and the computer user. The use of Windows is described, for example, in Person, et al., Windows 3.1QuickStart, 1992. The window structure and user interface provided by Windows is controlled by a Microsoft specification, Multiple Document Interface (hereafter "MDI"), which is described, for example, in Petzold, Programming Windows 3.1, Chapter 18. The contents of each of these publications are expressly incorporated herein by reference.
The MDI protocol dictates where and when various windows may be displayed on a computer display screen. Generally speaking, windows are of two varieties: a parent window and a child window. Typically, a parent window is opened when a user initiates execution of an application program. As execution of the application program continues, the parent window opens various child windows which allow the user to access various functionality in the application program. For example, a parent window may be opened when a user initiates execution of a word processing program. The parent window will, in turn, open a child window corresponding to each document that the user is editing or creating.
The MDI protocol dictates where on the display screen a child window can appear with respect to the position of the parent window, and dictates the change in appearance of the parent and child windows in response to various windows activities such as closing or iconizing.
The MIDI protocol, however, suffers from a disadvantage in that child windows are always constrained to lie within a frame defined by the parent window. As more and more child windows are opened, this constraint results in needless clutter on the display screen, making it difficult for a user to find a desired child window and to navigate through all of the windows.
FIGS. 1A and 1B illustrate this situation with respect to an application program (hereinafter "Message Manager application program") which allows a user to send and receive multimedia messages, to manage an address book of addresses for multimedia messages, to create and edit and retrieve multimedia messages, and to dial out automatically for sending messages. Operation of a suitable Message Manager is described in detail in application Ser. No. 07/808,757, filed Dec. 17, 1991, the contents of which are incorporated herein by reference. FIGS. 1A and 1B illustrate how the MDI protocol affects the appearance of various windows that are displayed on screen 61 of a computer display terminal 62.
As shown in these figures, parent window 50 is opened when the user initiates execution of the Message Manager application program. Window 50 is provided with a header block 51, which includes a document control icon 52, a menu bar 54 and a minimize button 56. Selecting "minimize" button 56, or selecting "minimize" from a pull-down menu, reduces window 50 to an icon, that is a small graphical representation of window 50 which is displayed on screen 61. This process may be referred to as "iconizing". As will be understood by those of ordinary skill, document control icon 52 may be used to change the size or position of window 50 within display screen 61, for example, by selecting from the "move", "size", "minimize" and "maximize" menu items that are available from the pull-down menu that is displayed after document control icon 52 is selected. In addition, "Minimize" button 56 may be selected so as to minimize the screen quickly without the need for selecting from a pull-down menu.
Menu bar 54 extends horizontally across a top portion of window 50 and displays menu items available to the user, such as "file", "edit", "create", "help" and the like. Each of the menu items displayed on menu bar 54 in turn may include secondary menu items selectable from a pull-down menu. As will be understood to those skilled in the art, pull-down menus extend vertically downward from a menu item on menu bar 54 and may include various additional menu items which further specify the commands available for selection by the user.
Using a keyboard, a mouse, or the like, a user may select various items from menu bar 54 so as to initiate execution of a desired command by the computer. For example, a user may select a menu item or other object by pressing the "enter" key on a keyboard or by "clicking" a mouse on a desired item.
A window frame 63 is associated with window 50. Window frame 63, whose size may be manipulated and adjusted by the user, sets the maximum extent of operations that are controlled by parent window 50 and the Message Manager application program. That is, anything on screen 61 outside of frame 63 is not associated with the Message Manager application program while anything within frame 63 is.
Each window 50 may itself display zero or more document icons 57 or zero or more child windows 58. Child windows may hereinafter be referred to as "document windows" even though, as illustrated in FIG. 1A, the child window 58 might not necessarily contain a document (in FIG. 1A window 58 is a "dialer"). Document icons 57 are small representations that, when selected by the user, become document windows 58. Like window 50, document windows 58 may also be provided with a document control icon and a minimize button, but typically document windows 58 are not provided with menu bars. The menu items displayed on menu bar 54 apply to document windows 58.
Document windows 58 contain the data or document on which the application programs represented by parent window 50 work. The sizes and positions of document windows 58 displayed in parent window 50 may be varied by the user, for example, by "dragging" the document window across the screen. The MDI protocol, however, constrains display of child windows 58 such that no part of window 58 may be moved beyond frame 63. Thus, as shown in FIG. 1A, although an attempt has been made to move child window 58 beyond the lower left boundary of frame 63, the MDI protocol does not permit display of any portion of document window 58 that would have extended beyond frame 63.
This constraint can result in unnecessarily cluttered displays. For example, as shown in FIG. 1B, a user has opened a second document window 58. However, because of the constraint that no portion of a document window can extend beyond frame 63, one document window partially overlaps and obscures the other document window. Thus, there is a need for a user interface for multiple child (or document) windows which does not constrain the position of the child windows to lie within a frame defined by the parent window.
One commonly accepted reason for the constraint imposed by the MDI protocol is to simplify how MDI controls the reaction of parent and child windows to various user commands to open, close and manipulate the windows. For example, when a user no longer desires to continue execution of the application program corresponding to window 50, the user may "close" that application by selecting a "close" menu item from document control icon 52. The MDI protocol governs the closing of windows, and will ensure that all open documents (or child) windows within parent window 50 are also properly closed down when parent window 50 is closed down.
Thus, there is a need to ensure that child windows positioned outside a parent window frame react properly to commands which effect the parent window or other windows.